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ABSTRACT 



Fast and efficient mathematical programming routines 
have been developed for network flow problems, but due to 
their complexity the average manager or lay analyst does not 
possess the mathematical or programming background required 
to construct the models or use the solution technology 
available. This problem is solved here by the development 
of an interactive network generating system designed to 
create, update, and solve a single-commodity network with 
only a minimal knowledge of network structure and only a 
rudimentary mastery of computer terminal use. This is 
accomplished through the interactive use of a set of FORTRAN 
programs which lead the user, step-by-step, through the con- 
struction of the network by a series of queries, and which 
links with GN2T, a machine independent FORTRAN program for 
the solution of capacitated network flow problems. 
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I. 



I NTRODUCI ION 

Over the past two decades, research in optimization of 
network flow models has resulted in the development of fast 
and efficient mathematical programming routines for the 
solution of this class of problems. Coupling this with the 
ready availability of high speed computers, network problems 
long viewed as impracticable are now routinely used by 
management. 

Due to the complexity of these algorithms and the intri- 
cacy of the models required to use them, the average manager 
or lay analyst frequently does not possess the mathematical 
or programming background required to construct the models 
or use the solution technology available. Thus, technically 
trained support personnel are required to construct the 
models, implement the appropriate routines, and make modifi- 
cations. As a result, the decision maker or individual for 
whom the system was designed is insulated from it. This 

provides the major impetus for this thesis to create an 

interactive general network model-building and optimization 
system that can be used by an individual who has only a 
basic knowledge of network structure and a general under- 
standing of computer terminal use. 
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Currently, industry is using network model-building and 
optimization systems as managemant support systems. For 
example, Hunt-Wesson Foods uses a multicommodity distribu- 
tion planning system based on a multicommodity network model 
[Ref. 1] and has demonstrated effective application of the 
system [Ref. 2]. But as is common with all the models of 
this type, most of the interface facilities are used by 
technical support personnel rather than the managers them- 
selves. Managers must make their needs known to technically 
trained intermediaries who translate these needs into speci- 
fications for computer runs, make the runs, and assist in 
interpreting the results. This can lead to delays and read- 
ily lends itself to possible misinterpretation by support 
personnel of the true intentions of the managers. 

A simple-to-use, interactive system would permit a man- 
ager to converse on a one-to-one basis with the model and 
provide an optimization process allowing for virtually 
immediate response to complicated network flow problems. 

The model developed here provides such capability for single 
commodity capacitated network flow problems, and can be 
expanded to handle more complex problems by the implementa- 
tion of the enhancements listed in chapter II. 



\ 
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The single commodity capacitated flow model and its spe- 
cializations constructed by the system are minimum cost net- 
work flow problems. The goal is to determine how (or at 
what rate) a good should flow through the arcs of a network 
to minimize shipment costs. The network is a directed graph 
defined by a set of m nodes, N, and a set of n arcs. A, with 
ordered pairs of nodes (tail, head) as elements indexed by k. 
For each arc there is a shipping cost per unit flow (or 
capacity), c, . Each node is either a supply node where 
units of goods enter the network, a demand node where units 
leave, or transhipment node. The problem is to minimize 
total cost with flows, x^, that satisfy the associated lower 
bounds and capacities and preserve the conservation of flow 
at each node: 

min z c,x, 

k k 

k e A 

s.t. E x^ - £ x k =b i* i € N, 

k e A with tail i k € A with head i 

1 < x < u ; k £ A 

k k k 

where b, = (supply if i is a supply node; -demand if i is a 

x 

demand node; 0 otherwise) (Ref. 3]. 
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This interactive network model- building system was 
designed for the user who has only a minimal knowledge of 
networks. If the user can identify the fact that the prob- 
lem to be solved can be represented as a single commodity 
capacitated flow network and has a basic knowledge of com- 
puter terminal use, then with the aid of the User’s Manual 
(Chapter III) he should be able to effectively use the sys- 
tem. The system leads the user through the construction of 
a network by a series of simple questions. The model may 
then be immediately (or repeatedly) solved with 3NET, a 
machine-independent FORTRAN program for solution of capaci- 
tated network flow problems [Ref. 3]. 

The features of the system may be summarized as follows 

1. The system is completly general for the class of 
problems at hand, allowing for a large number of diverse 
applications that include transport of goods, design of com 
munications and pipeline systems, assignment of people to 
jobs, routing of vehicles, bid evaluation, and production 
planning. For a comprehensive look at state-of-the-art net 
work model applications see [Ref. 4], 

2. The user may customize the system to the specific 
problem being solved by the interactive input of user 
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defined labels foe each node, naming the commodity passing 
through the network, and specifying the units of flow and 
units of cost per unit of flow, 

3. The system will create an entire network or allow 
for the modification of single elements of a previously con- 
structed network. 

4. The data-base requires minimal storage space. 

5. A series of checks are built into the system to pre- 
vent the construction of a mathematically inconsistent 
network. 

6. The user can execute commands by a single keystroke 
on a terminal. 

7. GNET one of the fastest and most efficient programs 
currently available for solving capacitated transhipment 
problems, thus allowing for virtually immediate solution of 
most network problems constructed. 

8. The system is reasonably portable between different 
computer installations. 

9. The system is designed for ease of expansion and 
modification . 
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II. 



SOFTWARE DESCRIPTION 



A. GENERAL 

The interactive network generating system consists of a 
driver program which co-ordinates the overall functioning of 
the system and eight subsystems which carry out the creation 
or modification of the network. 

1 . Data Base 

The data base is structured in the same form as the 
data base for GNET [Ref. 3]. This structure minimizes stor- 
age but still allows for ease of manipulation. The arcs are 
sorted so that all arcs with the same head are stored in 
contiguous space. This permits the list of head nodes to be 
replaced by a node-length array whose jth element is the 
location of the first arc with head j. Thus, the network is 
stored as three arc-length arrays: the tail nodes T( ), the 
costs C( ) , the minimum capacities MNCP( ) , and the maximum 
capacities MXCP ( ); also, three node-length arrays are used, 
the head node entries H( ) into T( ), supplies S( ) (-S ( ) 

denotes demand), and node labels L( ) . Figures 1 and 2 
[Ref. 3] show the data arrays for the network described in 
Figures 6, 7, and 8. 
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Figure 1: Node Data Arrays 
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Figure 2: Arc Data Arrays 
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2. Host Language 



The system has been developed in FORTRAN IV Extended 
[Ref. 5]. FORTRAN was chosen for the following reasons: 

a. FORTRAN is a general language available at most 
computer installations, so the system can be used with any 
contemporary hardware. Non-IBM systems may require some 
program modifications. 

b. Since FORTRAN is a high-level language, the 
development time has been low. 

c. The response time for each question is accepta- 
ble and there is little need for faster responses or 
enhanced efficiency. 

d. Extensions and changes for the system can be 
easily implemented. 

B. THE PROGRAM 
1 . Driver 

The driver program initializes the system and co- 
ordinates the interaction of all the subsystems [Fig. 3]. 

If a new file is being created, all counters are initialized 
at zero and all arrays are blank, allowing for the construc- 
tion of a new network. If an existing file is to be modi- 
fied or completed, the old file is read into the arrays and 
the counters are set at the appropriate values. 
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The overall co-ordination of the subsystems is 
maintained through the selection of the appropriate option 
from a menu for creating or updating the data file via user 
input. Once the action is completed, conl^rol is returned to 
the driver program and the user is prompted for the selec- 
tion of another option. The system has been designed to 
allow the user to return to the option list at any time dur- 
ing a terminal session by using a predefined character (ie. 
a **?*•) . 

2. S ub systems 

a. Adding Nodes 

Adding a node i to the network is accomplished 
by first reading in the label to be assigned to the node. 
Prior to entering the label into the label array L ( ) , it is 
checked against all existing labels to ensure that it has 
not previously been used. If the check is satisfactory then 
the label is stored in L(i) and the head node entry array 
element H(i) is created where H (i) = H(i+1) indicating that 

the predecessor arcs, as of now, are not created. A supply 
is then stored in S (i) , and finally the predecessor arcs are 
created by calling the arc-creating subroutine. 
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The user is also provided the capability of 
creating a node i "like" a node q. All data currently asso- 
ciated with node q is copied for node i. The user can then 
modify the costs, add or delete arcs, etc. for node i by 
returning to the option list and selecting the appropriate 
options to effect the changes, 
b. Creating Arcs 

An arc i, j can be created either in conjunction 
with the creation of a node or independently. If it is 
created in conjunction with a node, the head node index i is 
passed to the subroutine as the head node for the subsequent 
arc. If the arc is being created independently, the head 
node label must be entered at the terminal and its index 
determined by a search of the label array. 

When a head or tail node label is entered during 
the arc creation routine, the label is checked against all 
other existing labels. If a match is found, the index for 
the node label is used in all subsequent actions concerning 
that node. If a match is not found, then a node is created 
and flagged by placing a dummy value as the supply for the 
node (ie. S (i) = 2x10 9 ) to indicate that the node must be 
formally defined (as a source, sink, or pure transhipment 
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nods by entering a supply or demand) subsequently using the 
node creation option prior to completion of the network 
description. 

Once the head and tail node indices, i and j 
respectively, have been determined, the arc i, j is added to 
the network. The arc is linked to the head node i by set- 
ting H(q) = H (q) + 1 for all q > i. The tail node j is linked 
to the arc by expanding the tail array T( ) and inserting 
the index j at the appropriate location, T (H (i) ) = j. This 
procedure maintains the contiguous relationship of all arcs 
with same head node and allows for an orderly expansion of 
the network. 

c. Deleting Nodes 

When deleting a node i all arcs incident to that 
node must be deleted as well. For this reason all incident 
arcs are identified, their location stored, and then listed 
at the terminal prior to the node being deleted. This 
allows the user to preview the total effect of the node 
deletion . 

The predecessor arc indices are located directly 
from the head array (H{i) to H(i+1)-1). 
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Successor arc indices are located by a search of 
the tail array for the set of all k's such that T (k) = i. 

The head node index for one of the arcs k is identified by a 
sequential search of the head array for a node index h such 
that H ( h) < k < H (h + 1 ) -1 . 

After all incident arcs have been listed at the 
terminal, the user is provided an opportunity to abort the 
operation. If it is decided to abort, no change to the data 
base occurs. If it is decided to continue, the arcs and 
nodes are deleted. The arrays T( ), C( ), MNCP ( ), and 
MXCP ( ) are condensed to reflect the deletion of the arcs 
and similarly H( ), S( ), and L( ) are condensed to reflect 
the deletion of the node. The node indices in the array 
T( ) which are greater than the index of the node deleted 
must be decremented by one. The arc indices in the head 
array must be decremented sequentially by the number of pre- 
decessor arcs to that node that were deleted plus the number 
of predecessor arcs that were delated from all head nodes 
listed prior to the node being decremented. Through these 
index manipulation procedures the network structure can be 
efficiently maintained in situ. 
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d. Deleting Arcs 

When deleting an arc i, j, the arc is identified 
by the input of its head and tail node labels. When multi- 
ple arcs i,j exist the user must select the correct arc from 
the display of the respective arc costs and capacities. 

Once the arc is uniquely determined, it is deleted from the 
data base using the same procedure as that used for the 
deletion of an arc iin conjunction with the deletion of a 
node . 

e. Change Arc/Node Information 

The spelling of a node label, the supply at a 
node, cost for an arc, or an arc’s minimum or maximum capac- 
ity can be changed without any index manipulation other than 
that which is required for node or arc identification. Once 
the arc or node is identified by the appropriate label 
inputs, a listing of the data to be changed is presented at 
the terminal. The new data is then inserted into the appro- 
priate arrays. 

f. Printing Current Arc/Node Information 

A listing of all current arc and node informa- 
tion can be obtained by the selection of the appropriate 
option. The arc list is obtained by first sequentially 
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selecting a node index i. All predecessor arc indices are 
then readily identified as the set H (i) , . .., H(i+1)-1. 

Thus the tail node indices corresponding to the arcs are the 
set T(H(i) ) , . . . , T (H (i+1) - 1) . The arcs are then printed at 
the terminal listing the tail and head node labels, cost, 
and minimum and maximum capacities corresponding to the 
appropriate index [ie. L (T ( H (i+ n) ) ) TO L(i), C(H(i + n)), 

MNCP (H (i+n) ) , MXCP ( H (i+n) ) for n = 0, ..., H (i+ 1 ) -H (i) - 1 ]. 

The node information is printed at the terminal 
by sequentially listing L(i) and S(i) for i = 1, . .., m. 
g. Saving Data File 

If the user desires a permanent file of the data 
arrays, they are written to a predefined data file using 
unformatted WRITE statements which allow for minimum stor- 
age. By listing the array lengths first, the data can be 
easily retrieved using READ statements that sequence the 
arrays in the same order as the WRITE statements. The new 
file will write over any previously saved file with the same 
file name, making permanent any changes made to the old 
file, or creating an entirely new file. Appendix A is a 
FORTRAN listing of the write statements used in the system 
to permit users to recover networks with other programs. 
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h. Network Checks and Linking GNET 

Two network checks are run prior to the execu- 
tion of GNET. First the supply array S( ) is scanned for 
flags indicating undefined nodes. When a flag is encoun- 
tered the corresponding node label is printed at the termi- 
nal. Once the entire array has been checked the program 
returns to the option list to allow the user to formally 
define the listed node. If no undefined nodes are located 
the program continues on to the next check. 

The second check is for orphan nodes, isolated 
nodes with no incident arcs. The head array H( ) is first 
checked for all nodes that have no predecessor arcs (ie. 

H(i) = H(i + 1)). The set of node indices that have this 
property are then individually checked against the entire 
tail array T ( ) to determine if there are any successor arcs 
to these nodes; if a node in this set has no successor arcs, 
its label is listed at the terminal. GNET will execute with 
orphan nodes in the data arrays but the user is given the 
option of deleting the nodes to "clean-up 1 ’ the arrays or 
allowing them to remain as reference points for future net- 
work modifications. 
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After both checks are completed the system calls 
GNET as a subroutine to solve the final capacitated network 
flow problem. 

3. Data Input 

All user inputs are read as characters using an 80A1 
format. All leading blanks are ignored. If the first char- 
acter is a "?", then the program automatically returns to 
the option listing. This allows the user to terminate any 
operation at any time and return to the option list for 
assistance. 

A null response (ie. typing "enter" without typing a 
value) to a request for an integer input results in a zero 
being assigned- for the value. 

For "YES/NO" responses only the first letter is 
read. Any first character response (including a null 
response) other than a "Y" is assumed to be a "NO" answer. 

For each character string a SOUNDEX code is deter- 
mined. This is an alpha-numeric code used as a spelling 
error check [eg.. Ref. 6]. With reasonable accuracy a 
misspelled word's SOUNDEX code will match the code of the 
correct spelling of the word. Whan a search of the label 
array L ( ) is conducted the SOUNDEX codes are checked as 
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well. If the spelling of the newly typed label does not 

exist in the array but there is a SOUNDEX code match then a 

possible spelling error is assumed. The user is given the 
options of indicating no spelling error exists at which time 
the label is inserted into the array, or correcting the 
label currently in the data base with the newly typed label, 
or vice versa. 

After the SOUNDEX code has been determined for a 
label, the character string is stored in a two dimensional 
node-length array. Up to twenty characters are saved for 

each label entry. The last four characters are used for the 

SOUNDEX code. 

C. FUTURE ENHANCEMENTS 

Due to the complexity involved in expanding network flow 
problems to take into consideration more general "real 
world" applications there are no "easy to use" general 
interactive network generating systems in wide use today. 

For this reason the expansion or enhancement of this system 
is open to a myriad of possibilities. For instance: 

1. Expand the data base to create multicommodity net- 
work flow problems [Ref. 1]. 
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2 . 



Customize the system for multiperiod problems with 



intermediate inventory at the nodes. 

3. Customize the system so that production levels can 
be optimized at manufacturing nodes as well as flows to 
demand nodes. 

4. Allow for mixed integer programming problems where 
there are both fixed and variable costs on the arcs. 
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III. USER* S MANUAL 



A. INTRODUCTION 

The interactive network generating system is designed to 
create, update, and solve a single-commodity network with 
only a minimal knowledge of network structure and only a 
rudimentary knowledge of computer terminal operation. This 
is accomplished through the interactive use of a set of 
FORTRAN programs which lead the user, step-by-step, through 
the construction of the network by a series of questions and 
then links with GNET, a machine independent FORTRAN program 
for the solution of capacitated network flow problems 
[Ref. 3]. 

The entire system has been developed in FORTRAN language 
to allow for portability and possible use with other network 
optimization packages. 

The questions asked by the system are basically in Eng- 
lish sentence structure and self-explanatory in nature. 

A system of checks have been developed for the program 
that may prevent the user from creating a mathematically 
inconsistent network. 
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Appendix B is a dictionary of network terminology to 
assist the user in understanding the questions asked while 
creating the network. 

B. INPUT FORMATS 

All numerical inputs into the system must be integer 
values. They are entered one value per line in "free for- 
mat" (a value can be entered anywhere on a line) ; "right- 
justification" is not necessary. If an alpha character is 
entered where a numeric character is expected, the following 
warning is given: 

\ 

YOU HAVE ENTERED A NONINTEGER WHERE AN INTEGER IS REQUIRED. 
SEINPUT THE CGRRECT VALUE. 

A null response for a request for an integer input is 
assumed to be a zero value. 

A label input will truncate beyond twenty characters. 

All labels must be unique (no two nodes may have the same 
label) or a warning is given as is indicated in the follow- 
ing example: 

NEW YORK HAS ALREADY BEEN DEFINED AS A NODE NAME. EITHER 
INPUT ANOTHER NAME OR TYPE ? FOR ASSISTANCE. 
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Only a "Y" need be entered for a yes answer to any ques- 
tion requiring a "YES/NO" response. Any other response 
(including a null response) will be considered as a "NO" 
answer. 

C. INITIALIZING THE SYSTEM 

Upon starting the system the user is first presented a 
listing of system requirements followed by the question: 

ARE YOG CREATING A NEW FILE? YES/NO 

A "YES'* answer initializes the system and starts the con- 
struction of the network "from scratch". In this case, the 
user is then asked, 

WHAT IS THE NAME OF THE COMMODITY PASSING THROUGH THE 
NETWORK? 

>STEEL (">" indicates a keyboard prompt for user.) 

IN WHAT UNITS ARE THE FLOWS AND CAPACITIES MEASURED (IE. 

LBS, TONS, ETC) ? 

>TONS 

IN WHAT UNITS ARE THE COSTS GIVEN (IE. $/TONS) ? 

>$ 1 OO/TONS 
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The name and unit labels ace used in the future questions to 
aid in customizing the system for the individual user. The 
user must keep in mind that once a unit type has been 
defined,- all future capacities, flows, and costs must be 
expressed accordingly. 

A "NO” answer to the new file question results in the 
reading in of previously constructed network data arrays 
from a file that was created and saved during an earlier 
terminal session. This allows the user to create only part 
of the network at a time or change existing network data 
arrays. 

The dimensioning of the data arrays used in the system 
is dynamic, thus the user is asked, 

THE DIMENSIONS OF THE SYSTEM ARE FOR 1000 ARCS AND 500 

NODES. DO YOCJ WISH TO CHANGE THEM? YES/NO 

>YES 

HOW MANY NODES DO YOU WISH TO CREATE? 

>20 

HOW MANY ARCS DO YOU WISH TO CREATE? 

>60 

DATA REGION REQUIRED = 580 AVAILABLE = 12000 
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The dimensions once set will prevent the user from increas- 
ing the size of the network beyond the size of the user- 
defined values. Therefore the values should be larger than 
the actual dimensions of the network to be constructed to 
allow for errors or future expansion. When creating a new 
network default dimensioning is 500 nodes and 1000 arcs. 

D. MENU FOR CRE ATING/UPD AT ING DATA FILE 

Once the system is initialized either as a new network 
or with the parameters of a previously constructed network, 
the user is presented a menu of choices from which to create 
or update the network [Fig. 4]. Typing the corresponding 
line number, the program will present the appropriate series 
of questions to allow the user to accomplish the desired 
action. 

Typing a "?" at any time will return the user to this 
menu, thus allowing for the selection of another option to 
aid in the resolution of a possible problem. 

Cr eate Nod es 

Creating nodes is the usual starting point for the 
construction of a new network. The questions asked are 
basically self-explanatory. The following is an example of 
creating the twelfth node in a network with the commodity 
being STEEL [Fig. 7]: 
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1 . 

2 . 

3. 

4 . 

5. 

6 . 

7. 

8 . 



CREATE NODES 
CREATE ARCS 
DELETE EXISTING NODES 
DELETE EXISTING ARCS 

CHANGE CURRENT NODE/ARC INFORMATION WITHOUT CHANGING 
FILE INFORMATION 

PRINT LISTING OF CURRENT FILE INFORMATION 

SAVE A FILE 

STOP 



Figure 4: Menu for Creating/Updating Data File 
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HOW MANY NODES DO Y OD WANT TO CREATE? 



>1 

WHAT IS THE NAME OF NODE NO. 12? 

>MIAMI 

DO TOO WANT MIAMI TO 3E CREATED LIKE A PREVIOUSLY CREATED 
NODE (IE. ARCS TO AND FROM THE SAME LOCATIONS)? YES/NO 
>N0 

WHAT IS THE SUPPLY OF STEEL AT MIAMI IN TONS? 

>0 

WHAT IS THE DEMAND FOR STEEL AT MIAMI IN TONS? 

>16 

HOW MANY ARCS SHIPPING TO MIAMI DO YOU WANT TO CREATE? 

>1 

WHAT IS THE NAME OF THE TAIL NODE OF ARC NO. 1 THAT SHIPS TO 
MIAMI? 

>ATLANT A 

COST PER UNIT IN S100/TON? 

>34 

UNLIMITED CAPACITY? YES/NO 
>N0 

MAX. CAPACITY IN TONS? 

>16 
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MIN. CAPACITY IN TONS? 



>0 

The questions concerning supply and demand are 
related in such a way that if supply is greater than zero 
the user is not allowed to enter a demand. If supply is 
zero then a demand may be entered. If demand is also zero 
it is assumed that the node is a pure transhippment node. 

A negative supply is interpreted as a demand. A 
negative demand is interpreted as a supply. 

Only arcs shipping to the node being created can be 
constructed at this time. If the tail node has not yet been 
constructed the program will generate a dummy node with the 
same label as entered for the tail node. This dummy node 
must be formally created using the "ADD NODES" option prior 
to completion of the network, description . 

All arcs leading away from the node being created 
are constructed in conjunction with their head node at a 
later time. 

The user is also provided the option of creating a 
node "like" a previously created node (ie. arcs to and from 
the same locations, same costs, and same capacities) thus 
allowing for a minimal amount of work for the construction 
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of two or more similar nodes. By answering "YES" to the 
previous question the following action is taken: 

WHAT IS THE NAME OF THE NODE YOU WANT MIAMI TO BE LIKE? 

> AUSTIN 

MIAMI NOW HAS THE FOLLOWING STRUCTURE: 



DEMAND: 3 TONS 










ARCS: TO 


FROM 


COST 

$ 1 OO/TON 


MIN. CAP. 
TONS 


MAX .CAP. 
TONS 


MIAMI 


LOS ANGELES 


61 


0 


5 


MIAMI 


NEW YORK 


99 


0 


12 


MIAMI 


ATLANTA 


49 


0 


3 


MIAMI 


CHICAGO 


53 


0 


24 



TO MODIFY ANY OF THE ABOVE DATA RETURN TO THE MENU AND 
SELECT THE APPROPRIATE OPTION. 

2. Cr eate Arcs 

Arcs can be constructed independent of the creation 
of a node. The same questions and restrictions are required 
as for the construction of an arc in conjunction with the 
creation of a node (see previous example). 

3. Delete Ex ist i ng Nodes 

Deleting a node can cause the greatest change in a 
network's structure, thus it is also the most probable 
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operation to cause an error. All arcs incident to the node 
must be deleted as well. This can isolate other nodes leav- 
ing them completely disjoint from the rest of the network. 
For this reason the program will list the arcs omitted by 
the deletion of a node and allow the user the option to 
abort the operation prior to actual execution. 

The following is an example of deleting a node: 

WHAT IS THE NAME OF THE NODE YOU WANT TO DELETE? 

> ATLANTA 

DELETING ATLANTA RESULTS IN THE DELETION OF THE FOLLOWING 
ARCS: 



NEW YORK 


TO 


ATLANTA 


ATLANTA 


TO 


AUSTIN 


ATLANTA 


TO 


MIAMI 



DO YOU STILL WANT TO DELETE THIS NODE? YES/NO 

A "YES" response will cause the deletion of the node as well 
as the deletion of the listed arcs from the data arrays. A 
"NO" response will cause no change to the network to occur. 
4. Delete Exi s ti ng Arcs 

Since all arcs can be identified by their head and 
tail nodes only these labels are required to be entered in 
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order to delete a given arc as is indicated by the following 
example : 

% 

WHAT IS THE NAME OF THE HEAD NODE OF THE ARC ZOO ARE 
DELETING? 

>CHICAGO 

WHAT IS THE NAME OF THE TAIL NODE OF THE ARC ZOO ARE 
DELETING? 

>NEW TORK 

5. Change Curr ent Arc/ Nod e Information 

This option allows the user to change, update, or 
correct any element within the data base as long as the 
node-arc structure of the network is not altered. Opon 
selecting this, option, the user is presented the menu in 
Figure 5 from which to select the type of change desired. 
After the completion of a change, the program returns to the 
"MEND OF CHANGES”. To return to the ”MENO FOR 
CREATING/UPDATING DATA FILE” enter a ”?» at any time, 
a. Change/Correct Spelling of Node Label 

To change the spelling of a node label (ie. a 
misspelled label) the user is simply asked what label is to 
be changed and the new spelling as indicated in the follow- 
ing example: 
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1. CHANGE/CORRECT SPELLING OF NODE LA3EL 

2. CHANGE THE AMOUNT OF SUPPLY OR DEMAND AT A NODE 

3. CHANGE COST FOR AN ARC 

4. CHANGE CAPACITY FOR AN ARC 

Figure 5: Menu of Changes 
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WHICH NODS LABEL DO YOO WANT TO CHANGE? 



>DEN VAR 

WHAT IS THE NEW LABEL? 
>DENVER 



b. Change Amount of Supply or Demand 

When changing the amount of supply or demand at 
a node the user must first identify the node. This results 
in the display of a listing of the current supply or demand. 
The user then enters the new value. The following is an 
example of changing a demand node to a pure transhippment 
node : 

WHAT IS THE NAME OF THE NODE FOR WHICH YOU WANT TO CHANGE 
SUPPLY OR DEMAND? 

>A USTI N 

THE DEMAND IS CURRENTLY 8 TONS. 

WHAT IS THE NEW SUPPLY AT THIS NODE? 

>0 

WHAT IS THE NEW DEMAND AT THIS NODE? 
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>0 



c. Change Cost for an Arc 

When changing the cost for an arc the user must 
first identify the arc to be changed. This results in the 
display of a listing of the current cost. The user then 
enters the new value. The following is an example of chang- 
ing the cost on an arc: 

WHAT IS THE NAME OF THE HEAD NODE OF THE ARC ON WHICH Y00 
WANT TO CHANGE COST OR CAPACITY? 

>A OSTIN 

WHAT IS THE NAME OF THE TAIL NODE OF THIS ARC? 

>LOS ANGELES 



CURRENTLY, COST: 




61 


$ 1 0O/TO N 


MAX. 


CAPACITY: 


5 


TONS 


MIN. 


CAPACITY: 


0 


TONS 



WHAT IS THE NEW COST? 
>75 



d. Change Capacity of an Arc 

Changing the capacity of an arc is done in the 
same manner as is done for changing the cost for an arc. 
Only the final question changes as follows: 

IS THE NEW MAX. CAPACITY (JN LIMITED? YES/NO 
>NO 
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WHAT IS THE NSW MAX. CAPACITY? 



>7 

WHAT IS THE NEW MIN. CAPACITY? 

>0 

6. Print Listing of Cu rre nt File Information 

This option allows the user to print a listing of 
node and arc information currently in the data base. The 
user is given the option of printing the listing at the ter- 
minal and/or printer. Figures 6 and 7 are examples of the 
listings for a given network. Figure 8 is a graphical 
representation of the network. 

7. Sa_ve a File 

Either at the end of a terminal session or periodi- 
cally during the session the user can save the file just 
completed by selecting option seven. This causes the pro- 
gram to write over any previously saved file thus creating a 
new file or correcting all items that have been changed 
prior to the save option execution. This allows the user to 
create a permanent file that can be read by the system at a 
later date. Only through the execution of this option will 
any change to the permanent file occur. 
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ARC 


FROM 


TO 


COST 

$ 1 0 O/TON 


MIN CAP 
TONS 


MAX CAP 
TONS 


1 


NEW YORK 


CHICAGO 


34 


0 


1 1 


2 


CHICAGO 


OMAHA 


23 


0 


6 


3 


LOS ANGELES 


SALT LAKE CITY 


28 


0 


10 


4 


NEW YORK 


ATLANTA 


45 


5 


25 


5 


LOS ANGELES 


SEATTLE 


57 


0 


21 


6 


SALT LAKE CITY 


DENVER 


24 


0 


5 


7 


LOS ANGELES 


DENVER 


56 


0 


7 


8 


OMAHA 


DENVER 


19 


0 


9 


9 


LOS ANGELES 


AUSTIN 


61 


0 


5 


10 


NEW YORK 


AUSTIN 


99 


0 


12 


1 1 


ATLANTA 


AUSTIN 


48 


0 


3 


12 


CHICAGO 


AUSTIN 


53 


0 


24 


13 


CHICAGO 


MINNEAPOLIS 


26 


0 


8 


14 


OMAHA 


MINNEAPOLIS 


20 


0 


2 


15 


NEW YORK 


WASHINGTON 


14 


10 


23 


16 


ATLANTA 


MIAMI 


34 


0 


16 



Figure 6: arc Report 
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ODE 


NAME 


SUPPLY 

TONS 


1 


LOS ANGELES 


34 


2 


NEW YORK 


56 


3 


CHICAGO 


5 


4 


OMAHA 


0 


5 


SALT LAKE CITY 


-5 


6 


ATLANTA 


-9 


7 


SEATTLE 


-18 


8 


DENVER 


-15 


9 


AUSTIN 


-8 


10 


MINNEAPOLIS 


-3 


11 


WASHINGTON 


-21 


12 


MIAMI 


-16 



A NEGATIVE SUPPLY IMPLIES DEMAND 
Figure 7: Node Report 
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Graphical Representation of Example Network 



8. Run Network C he cks and Link GNET 

Prior to the execution of GNET two checks are run on 
the network. The first check is to determine whether all 
nodes have been defined using the "CREATE NODES" option. 

All dummy nodes that were created while constructing arcs 
and not subsequently defined are listed as indicated in the 
following example: 

THE FOLLOWING NODES HAVE NOT EXPLICITLY BEEN DEFINED (IE. IT 
HAS NOT BEEN DETERMINED WHETHER THE NODE IS A SOURCE, SINK, 
OR PURE TRANSHIPMENT) : 

MONTEREY 

YOU MUST ADD THE NODES EXPLICITLY TO THE DATA BASE TO ALLOW 
A SOLUTION TO THE NETWORK TO BE FOUND. 

The user must create these nodes before the program will 
allow execution of GNET. 

If all nodes are defined the user will be informed 
by the following message: 

ALL NODES DEFINED 

The second check is for orphan nodes, isolated nodes 
with no incident arcs. The user is presented with the fol- 
lowing listing: 
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THE FOLLOWING NODE(S) ARE ORPHANS (IE. NO INCIDENT ARCS): 
MIAMI 

GNET WILL WORK WITH THESE NODES LEFT IN THE DATA BASE, BUT 
DO YOU WANT THEM DELETED? YES/NO 

A "YES" response will cause the listed nodes to be perma- 
nently deleted from the data base. The deletion will not 
effect the solution to the network problem. A "NO" response 
will leave the nodes in the data arrays, thus allowing the 
user to add arcs to these nodes at a later date without for- 
mally recreating the nodes. 

Once the checks are successfully completed the pro- 
gram sends the completed network data base to GNET. GNET 
performs some additional checks, such as for improper scal- 
ing of cost coefficients, problem feasibility, etc. For 
more information concerning the internal operation of GNET 
see [Ref. 3]. If all network checks are successful the 
final optimal solution will be listed as in Figures 9 and 
10 . 

9 . Stop 

The "STOP” option simply terminates the terminal 
session, but prior to the physical termination the user is 
provided one more opportunity to "SAVE A FILE". 
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FROM 


TO 


COST 

$ 100/TON 


MIN. CAP 
TONS 


FLOW 

TONS 


MAX. CAP 
TONS 


NEW YORK 


CHICAGO 


34 


0 


10 


1 1 


CHICAGO 


OMAHA 


23 


0 


6 


6 


LOS ANGELES 


SALT LAKE CITY 


28 


0 


10 


10 


NEW YORK 


ATLANTA 


45 


5 


25 


25 


LOS ANGELES 


SEATTLE 


57 


0 


18 


21 


SALT LAKE CITY DENVER 


24 


0 


5 


5 


LOS ANGELES 


DENVER 


56 


0 


4 


7 


OMAHA 


DENVER 


19 


0 


6 


9 


LOS ANGELES 


AUSTIN 


61 


0 


2 


5 


NEW YORK 


AUSTIN 


99 


0 


0 


12 


ATLANTA 


AUSTIN 


48 


0 


0 


3 


CHICAGO 


AUSTIN 


53 


0 


6 


24 


CHICAGO 


MINNEAPOLIS 


26 


0 


3 


8 


OMAHA 


MINNEAPOLIS 


20 


0 


0 


2 


NEW YORK 


WASHINGTON 


14 


10 


21 


23 


ATLANTA 


MIAMI 


34 


0 


16 


16 


CO ST= 4723. 


Figure 9: Final 


Solution 


Arc Report 







50 



NODE NODE LA3EL 



SUPPLY 

TONS 



DUAL VARIABLES 
$1 OO/TON 



1 


LOS ANGELES 


34 


-26 


2 


NEW YORK 


56 


0 


3 


CHICAGO 


5 


-34 


4 


OMAHA 


0 


-63 


5 


SALT LAKE CITY 


-5 


-54 


6 


ATLANTA 


-9 


-45 


7 


SEATTLE 


-18 


-83 


8 


DENVER 


-15 


-82 


9 


AUSTIN 


-8 


-87 


10 


MINNEAPOLIS 


-3 


-60 


1 1 


WASHINGTON 


-21 


-14 


12 


MIAMI 


-16 


-79 



Figure 10: Final Solution Node Report 
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2. ADDITIONAL SYSTEM CHECKS AND SAFEGUARDS 
1 • Sp e llin g Errors 

A new label is always checked with existing labels 
already in the data base prior to its insertion in the data 
base. A spelling error check is made by the comparison of a 
coded form of the labels [Ref. 6]. If the. codes match but 
the exact spelling of the labels do not, a possible spelling 
error is assumed and the user is given the option to correct 
the error. This helps prevent the creation of two nodes, 
due to a spelling error, when the user intends only one. 

The following is presented to the user to correct the proba- 
ble error: 

YOU HAVEA POSSIBLE SPELLING ERROR. TYPE THE CORRESPONDING 
LINE NUMBER FOR THE APPROPRIATE ACTION. 

1. NO SPELLING ERROR EXISTS 

2. MISSPELLED: CHICEGO CORRECT WITH: CHICAGO 

3. MISSPELLED: CHICAGO CORRECT WITH: CHICEGO 

A response of " 1" will cause no change to occur and the pro- 
gram will continue. A response of "2 M or "3' 1 will cause the 

first label to be replaced by the second permanently. 



52 



2. Minimum Greater Than Maximum 

If the minimum capacity is greater than the maximum 
for a given arc the following warning is displayed: 

100 HAVE A MIN. CAPACITY GREATER THAN THE CORRESPONDING MAX. 
PROVIDE THE CORRECT VALUES. 

Simply provide the correct values in the proper order when 
prompted for the new maximum and minimum capacities. 

3. Mu l ti ple Ar cs 

Both the network generating system amd GNET will 
admit multiple arcs. When the system is required to iden- 
tify a specific multiple arc the user must identify the 
correct arc by its corresponding cost or capacity as is 
indicated in the following example: 

THERE ARE MULTIPLE ARCS BETWEEN THE NODES NEW YORK AND 
CHICAGO. TYPE THE CORRESPONDING LINE NUMBER OF THE ARC YOU 
WANT DELETED. 

1. COST: 34 SIOO/TON, MAX. CAP. : 11 TONS, MIN. CAP.: 0 TONS 

2. COST: 25 $1 OO/TON , MAX. CAP.: 7 TONS, MIN. CAP. : 0 TONS 
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APPENDIX A 



IMPLICIT INTEGER (A-Z) 



REWIND 




WRITE 

WRITE 



1=1,5) 



(CP ( J7 ) , J7=1,N) 



Number of arcs: N 

Number of nodes: M 

Commodity label: COMOD 

Capacity units label: CAPLAB 

Cost units label: CSTLAB 

Tail nodes: T 

Costs: C 

Maximum capacities: MXCP 

Minimum capacities: MNCP 

Maximum - Minimum capacities: CP 

Head node entries into T( ) : H 

Supplies: S 

Node labels: L 
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APPENDIX B 

Arc A vector, a unidirectional means of indicating commod- 
ity transportation among locations, or routes. 

Alpha Character Any letter in the English alphabet (ie. 

A, B , C, Z] . 

Cost Per Unit The cost of shipping one unit of a commodity 
across a given arc. 

Dual Variable A price associated with a constraint of the 
original (primal) problem (ie. marginal cost or shadow 
price) . 

Head Node An incident node at the end of an arc to which 
the arc flow is moving. 

Integer Whole number. 

Max. Capacity/Upper 3ound The maximum amount of a commodity 
that can flow across a given arc. 

Min. Capacity/Lower Bound The minimum amount of a commodity 
that can flow across a given arc. 

Multiple Arcs More than one arc between the same two nodes 
with their flow orientation in the same direction. 
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Nods A location or terminal connected by arcs and served 
by whatever physical means of transportation is 
associated with the arcs. 

Numeric Character A single digit (ie. 0, 1, . .., 9). 

Orphan Node An isolated node with no incident arcs. 

Predecessor Arc For a given node an arc with its head at 
that node. 

Prompt Indicated in this text as '•>" , the prompt character 
indicates that a user-supplied input is required before 
further execution. 

Sink Node A node with demand. 

Source Node A node with supply. 

Successor Arc For a given node an arc with its tail at 
that node. 

Transhi ppment Node A node with zero supply and zero 
demand. 
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